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Abstract.  A  controversial  issue  in  the  formal  methods  community  is 
the  degree  to  which  mathematical  sophistication  and  theorem  proving 
skills  should  be  needed  to  apply  a  formal  method  and  its  support  tools. 
This  paper  describes  the  SCR  (Software  Cost  Reduction)  tools,  part 
of  a  “practical”  formal  method — a  method  with  a  solid  mathematical 
foundation  that  software  developers  can  apply  without  theorem  proving 
skills,  knowledge  of  temporal  and  higher  order  logics,  or  consultation  with 
formal  methods  experts.  The  SCR  method  provides  a  tabular  notation 
for  specifying  requirements  and  a  set  of  “light-weight”  tools  that  detect 
several  classes  of  errors  automatically.  The  method  also  provides  support 
for  more  “heavy-duty”  tools,  such  as  a  model  checker.  To  make  model 
checking  feasible,  users  can  automatically  apply  one  or  more  abstraction 
methods. 


1  Introduction 

Given  the  high  frequency  of  requirements  errors,  the  serious  accidents  they  may 
cause,  and  the  high  cost  of  correcting  them,  tools  that  aid  software  developers 
in  the  early  detection  of  requirements  errors  are  crucial.  To  be  effective,  the 
tools  must  be  usable  by  software  developers  on  industrial-strength  projects  and 
should  be  based  on  a  formal  model  of  requirements.  The  formal  model  provides 
a  solid  basis  for  formal  analysis  of  the  specification,  which  detects  many  classes 
of  errors  automatically. 

For  a  requirements  tool  to  be  useful  to  software  developers,  the  tool  must 
be  part  of  a  development  method  that  provides  guidance  on  those  decisions 
the  requirements  specification  should  record  and  those  it  should  not  (i.e. ,  the 
method  distinguishes  requirements  decisions  from  design  decisions)  and  guidance 
on  making,  evaluating,  and  recording  the  decisions.  The  development  method 
should  also  provide  notations  that  software  developers  can  apply  easily  in  con¬ 
structing  a  requirements  specification.  Finally,  the  method  should  not  require 
the  developers  to  be  experts  in  the  formal  model  underlying  the  tool. 

The  SCR  (Software  Cost  Reduction)  requirements  method  is  a  formal  method 
based  on  tables  for  specifying  the  requirements  of  safety-critical  software  sys¬ 
tems.  Designed  for  use  by  engineers,  the  method  has  been  applied  to  a  variety 
of  practical  systems,  including  avionics  systems,  telephone  networks,  and  nu¬ 
clear  power  plants.  Originally  formulated  by  NRL  researchers  to  document  the 
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requirements  of  the  Operational  Flight  Program  (OFP)  of  the  US  Navy’s  A- 7 
aircraft  [11,  1],  SCR  has  been  used  in  practice  by  a  number  of  industrial  orga¬ 
nizations,  such  as  Grumann,  Bell  Laboratories,  Ontario  Hydro,  and  Lockheed, 
to  specify  software  requirements.  For  example,  in  1993-94,  Lockheed  used  SCR 
tables  to  specify  the  complete  requirements  of  the  C-130J  OFP  [5],  a  program 
containing  more  than  230K  lines  of  Ada  code. 

Introduced  in  1995  [8,  9],  SCR*  is  an  integrated  suite  of  tools  supporting 
the  SCR  requirements  method.  Figure  1  illustrates  SCR*,  which  includes  a  spec¬ 
ification  editor  for  creating  a  requirements  specification,  a  dependency  graph 
browser  for  displaying  the  variable  dependencies  in  the  specification,  a  consis¬ 
tency  checker  for  detecting  well-formedness  errors  (e.g.,  type  errors  and  miss¬ 
ing  cases),  a  simulator  for  validating  the  specification,  and  a  model  checker  for 
checking  application  properties.  Currently,  more  than  50  organizations  in  the  US, 
Canada,  UK,  and  Germany,  including  industrial  and  government  organizations 
as  well  as  universities,  are  experimenting  with  SCR*. 


Fig. 1.  SCR*:  Tools  supporting  the  SCR  requirements  method 

To  date,  SCR*  has  been  applied  successfully  in  three  external  pilot  projects. 
In  the  first,  researchers  at  NASA’s  IVAV  Facility  used  SCR*  to  detect  missing 
cases  and  nondeterminism  in  the  prose  requirements  specification  of  software  for 
the  International  Space  Station  [4].  In  the  second  project,  engineers  at  Rockwell- 
Collins  used  SCR*  to  expose  24  errors,  many  of  them  serious,  in  the  requirements 
specification  of  an  example  flight  guidance  system  [14].  Of  the  detected  errors, 
a  third  were  uncovered  in  constructing  the  specification,  a  third  in  running  the, 
consistency  checker,  and  the  remaining  third  in  executing  the  specification  with 
the  simulator.  In  a  third  project,  researchers  at  the  JPL  (Jet  Propulsion  Labo¬ 
ratory)  used  SCR*  to  analyze  specifications  of  two  components  of  NASA’s  Deep 
Space-1  spacecraft  for  errors  [13]. 

In  a  fourth  pilot  project,  NRL  applied  the  SCR  tools,  including  a  newly  in¬ 
tegrated  model  checker  [3],  to  a  sizable  contractor-produced  requirements  spec- 


ification  of  the  Weapons  Control  Panel  (WCP)  for  a  safety-critical  US  military 
system  [10].  The  tools  uncovered  numerous  errors  in  the  contractor  specification, 
including  a  serious  safety  violation.  Translating  the  contractor  specification  into 
the  SCR  tabular  notation,  using  SCR*  to  detect  specification  errors,  and  build¬ 
ing  a  working  prototype  of  the  WCP  required  only  one  person-month,  thus 
demonstrating  the  utility  and  cost-effectiveness  of  the  SCR  method. 

2  The  SCR  Requirements  Model 

An  SCR  requirements  specification  describes  the  required  system  behavior  as 
the  composition  of  a  nondeterministic  environment  and  a  (usually)  deterministic 
system  [7].  The  system  environment  contains  monitored  and  controlled  quanti¬ 
ties,  quantities  that  the  system  monitors  and  controls.  The  environment  nonde- 
terministically  produces  a  sequence  of  input  events,  where  an  input  event  is  a 
change  in  some  monitored  quantity.  Beginning  in  some  initial  state,  the  system 
responds  to  each  input  event  in  turn  by  changing  state  and  possibly  changing 
one  or  more  controlled  quantities.  In  SCR,  the  system  behavior  is  assumed  to  be 
synchronous — the  system  completely  processes  one  input  event  before  processing 
the  next  input  event. 

The  SCR  formal  model,  a  special  form  of  the  classic  state  machine  model, 
represents  a  system  A  as  a  4-tuple,  S  =  (S,  So,  Em ,  T),  where  S'  is  a  set  of  states, 
So  C  S'  is  the  initial  state  set,  Em  is  the  set  of  input  events,  and  T  is  the  transform 
describing  the  allowed  state  transitions  [7].  In  the  formal  model  presented  in 
[7],  the  transform  T  is  deterministic,  a  composition  of  smaller  functions  called 
table  functions,  derived  from  the  tables  in  an  SCR  specification.  The  formal 
model  requires  the  information  in  each  table  to  satisfy  certain  properties.  These 
properties  guarantee  that  each  table  describes  a  total  function. 

In  SCR,  two  relations,  NAT  and  REQ,  describe  the  required  system  behavior. 
NAT  specifies  the  natural  constraints  on  the  system  behavior — constraints  im¬ 
posed  by  physical  laws  and  the  system  environment.  REQ  specifies  the  relation 
that  the  system  must  enforce  between  the  monitored  and  controlled  quantities. 
To  specify  REQ  concisely,  the  SCR  method  uses  mode  classes,  conditions,  and 
events.  A  mode  class  organizes  the  system  states  into  equivalence  classes,  each 
called  a  mode.  The  SCR  model  includes  a  set  RF  containing  the  names  of  all 
variables  (e.g.,  monitored  and  controlled  variables,  mode  classes)  in  a  given  spec¬ 
ification  and  a  function  mapping  each  variable  in  RF  to  a  set  of  values.  In  the 
model,  a  state  is  a  function  mapping  each  variable  in  RF  to  its  value,  a  condition 
is  a  predicate  defined  on  a  system  state,  and  an  event  is  a  predicate  defined  on 
two  system  states  when  any  state  variable  changes. 

3  The  SCR  Tools 

Specification  Editor.  To  create,  modify,  or  display  a  requirements  specifica¬ 
tion,  the  user  invokes  the  specification  editor  [8].  Each  SCR  specification  is  orga¬ 
nized  into  dictionaries  and  tables.  The  dictionaries  define  the  static  information 
in  the  specification,  such  as  the  names  and  values  of  variables  and  constants,  the 
user-defined  types,  etc.  The  tables  specify  how  the  variables  change  in  response 


to  input  events.  One  important  class  of  tables  specifies  the  behavior  of  controlled 
variables. 


Dependency  Graph  Browser.  Understanding  the  relationship  between  dif¬ 
ferent  parts  of  a  large  specification  can  be  difficult.  To  address  this  problem, 
the  Dependency  Graph  Browser  (DGB)  represents  the  dependencies  among  the 
variables  in  a  given  SCR  specification  as  a  directed  graph  [9].  By  examining 
this  graph,  a  user  can  detect  errors  such  as  undefined  variables  and  circular 
definitions.  The  user  can  also  use  the  DGB  to  display  and  extract  subsets  of 
the  dependency  graph,  e.g.,  the  subgraph  containing  all  variables  upon  which  a 
selected  controlled  variable  depends. 

Consistency  Checker.  The  consistency  checker  [7,  9]  analyzes  a  specification 
for  properties  derived  from  the  SCR  requirements  model.  It  exposes  syntax  and 
type  errors,  variable  name  discrepancies,  missing  cases,  unwanted  nondetermin¬ 
ism,  and  circular  definitions.  When  an  error  is  detected,  the  consistency  checker 
provides  detailed  feedback  to  facilitate  error  correction.  A  form  of  static  analy¬ 
sis,  consistency  checking  is  performed  without  execution  of  the  specification  or  a 
reachability  analysis  and  is  hence  more  efficient  than  model  checking.  In  devel¬ 
oping  an  SCR  specification,  the  user  normally  invokes  the  consistency  checker 
first  and  postpones  more  heavy-duty  analysis  such  as  model  checking  until  later. 
By  exploiting  the  special  properties  guaranteed  by  consistency  checking  (e.g., 
determinism),  later  analyses  can  be  more  efficient  [3]. 

Simulator.  To  validate  a  specification,  the  user  can  run  the  simulator  [9]  and 
analyze  the  results  to  ensure  that  the  specification  captures  the  intended  behav¬ 
ior.  Additionally,  the  user  can  define  invariant  properties  believed  to  be  true  of 
the  required  behavior  and,  using  simulation,  execute  a  series  of  scenarios  to  de¬ 
termine  if  any  violate  the  invariants.  To  provide  input  to  the  simulator,  the  user 
either  enters  a  sequence  of  input  events  or  loads  a  previously  stored  scenario. 

The  simulator  supports  the  construction  of  front-ends,  tailored  to  particular 
application  domains.  One  example  is  a  customized  front-end  for  pilots  to  use  in 
evaluating  an  attack  aircraft  specification  (see  Figure  2).  Rather  than  clicking 
on  monitored  variable  names,  entering  values  for  them,  and  seeing  the  results  of 
simulation  presented  as  variable  values,  a  pilot  clicks  on  visual  representations  of 
cockpit  controls  and  sees  results  presented  on  a  simulated  cockpit  display.  This 
front-end  allows  the  pilot  to  move  out  of  the  world  of  requirements  specification 
and  into  the  world  of  attack  aircraft,  where  he  is  the  expert.  Such  an  interface 
facilitates  customer  validation  of  the  specification.  A  second  customized  front- 
end,  part  of  the  WCP  prototype  mentioned  above,  has  also  been  developed. 

Model  Checker.  Recently,  the  explicit  state  model  checker  Spin  [12]  was  in¬ 
tegrated  into  SCR*  [3].  After  using  SCR*  to  develop  a  formal  requirements 
specification,  a  developer  can  obtain  an  automatic  translation  of  the  specifica¬ 
tion  into  Promela,  the  language  of  Spin,  and  then  invoke  Spin  within  the  toolset 
to  check  properties  of  the  specification.  Currently,  the  model  checker  analyzes 
invariant  properties.  The  user  can  use  the  simulator  to  demonstrate  and  validate 
any  property  violation  detected  by  Spin. 


Fig.  2.  Customized  simulator  front-end  for  an  attack  aircraft  specification 

The  number  of  reachable  states  in  a  state  machine  model  of  real-world  soft¬ 
ware  is  usually  very  large,  sometimes  infinite.  To  make  model  checking  practical, 
we  have  developed  sound  methods  for  deriving  abstractions  from  SCR  specifica¬ 
tions  [3].  The  methods  are  practical:  none  requires  ingenuity  on  the  user’s  part, 
and  each  derives  a  smaller,  more  abstract  model  automatically.  Based  on  the 
property  to  be  analyzed,  these  methods  eliminate  irrelevant  variables  as  well 
as  unneeded  detail  from  the  specification.  For  example,  prior  to  invoking  Spin 
to  check  the  WCP  specification  for  a  safety  property,  we  used  our  abstraction 
methods  to  automatically  reduce  the  number  of  variables  from  258  to  55  and 
to  replace  several  real- valued  variables  with  finite- valued  variables,  thus  making 
model  checking  feasible  [10]. 

4  Comparison  with  Other  Tools 

The  method  most  closely  related  to  SCR  is  the  Requirements  State  Machine 
Language  (RSML)  and  associated  tools  [6].  In  [2],  Anderson  et  ah  describe  the 
use  of  the  model  checker  SMV  to  analyze  a  component  of  the  TCAS-II  spec¬ 
ification  expressed  in  RSML.  Unlike  our  approach  to  limiting  state  explosion 
which  reduces  the  specification  by  applying  sound  abstraction  methods,  Ander¬ 
son  et  al.  propose  a  more  efficient  encoding  for  the  BDD  representation  of  the 


RSML  specification.  More  recently,  Park  et  al.  [15]  have  used  the  Stanford  Va¬ 
lidity  Checker  (SVC)  to  check  the  consistency  of  RSML  specifications.  Their 
approach  is  similar  to  that  used  by  the  consistency  checker  in  SCR*  [7,  9]. 

SCR*  can  be  distinguished  in  three  major  ways  from  other  tools.  First,  unlike 
most  commercial  tools  for  requirements  specification,  SCR*  has  a  solid  math¬ 
ematical  foundation,  thus  allowing  sophisticated  analyses,  such  as  consistency 
checking  and  model  checking,  largely  unsupported  by  current  tools.  Second, 
the  SCR  tools,  unlike  most  research  tools,  have  a  well  designed  user  interface, 
are  integrated  to  work  together,  and  provide  detailed  feedback  when  errors  are 
detected  to  facilitate  their  correction.  Finally,  users  of  SCR*  can  do  consider¬ 
able  analysis  without  interaction  with  application  experts  or  formal  methods 
researchers,  thereby  providing  formal  methods  usage  at  low  cost. 
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